@raclim Please review my PR . I have updated the required changes.

@Harshit-7373 Maybe you Forget the mention Issue Number????????. It would be better to Provide issue number for the better tracking.

@Jatin24062005 Yes , I forgot to mention the issue number in the PR . I have now updated the PR description. The issue number is #3081

Thanks @Harshit-7373 for taking a look into this!

I think the general implementation here is correct! One other change that could've been helpful here is to have the text content align more with some of the suggestions within the attached issue.

Since this is a somewhat major outward facing change, I think we might need further discussion on how it's implemented, when it should be introduced to the community, and ensure it doesn't conflict with other changes that are happening within the p5.js library and p5.js editor. I think this comment mentions the discussion on the proposed guidelines around the describe() function that's happening within the p5.js library, which I think we might want to wait to see what's happening there before implementing here.

Since this might take more planning first and isn't ready to be implemented yet, I'm going to close this for now. However, please feel free to revisit this once the discussion on it has been settled!

This would be great to add! How about this for the comment text, so it's a bit more of a guidance:

"Did you know? The canvas element is not accessible to screen readers, but it can be! Use describe(..) to create a accessible description of your sketch. Read more about screen reader support here: https://p5js.org/tutorials/writing-accessible-canvas-descriptions/"

Maybe the link in comments is excessive 😅

Hey @Harshit-7373 just wanted to update that after some internal discussion @ksen0 and I thought it would be great to revisit this issue, so I reopened your PR!

"Did you know? The canvas element is not accessible to screen readers, but it can be! Use describe(..) to create a accessible description of your sketch. Read more about screen reader support here: https://p5js.org/tutorials/writing-accessible-canvas-descriptions/"

I really love this version of the commented text! I'm wondering if the last line with the link might not be needed, and could also pose an accessibility issue if the linked text isn't descriptive? Please feel free to add any additional thoughts on this here!

This is great! I'm really glad to see more encouragement to use describe().

A couple small thoughts:

• Many beginners might not know what a "canvas element" is. Referring to "your sketch" might be clearer.
• Also, not everyone knows what a screen reader is. It could help to focus less on the tech and more on the people it’s for.

A few possible alternatives:

// Help blind or low-vision users understand your sketch
describe("Write description of your project");

// Describe your sketch for people using screen readers (e.g. blind or low-vision users)
describe("Write description of your project");

// This description is read aloud to blind or low-vision users who use a screen reader
describe("Write description of your project");

Thanks so much for this exciting suggestion! I agree with @SableRaf on prioritizing beginners in the explanation of describe().

I also think that if the user has never seen an example of an alt-text in the past, "Write description of your project" can be broadly interpreted in this context. In this case, I'd recommend prioritizing doing over telling by showing an example of alt-text inside describe(). For instance:

function setup() {
  createCanvas(400, 400);
  background(220);
  // Help blind or low-vision users understand your sketch
  describe("A 400 by 400 pixel gray canvas.");
}

This would also be more aligned with how describe() gets communicated under p5.js website's references (here's one example). And if a user is still confused by their initial encounter with describe() in the editor, this provides another route for them to put the two together once they dive into the reference page.

Hi all,

I recently conducted some user testing with a 9th grader withs some prior block-based-coding experience (Amelie) and a group of 17 teachers to better understand reactions to including the describe() function in the starter code. The results were nuanced and helpful.
What we heard:

• Everyone we spoke with values the goal of increasing accessibility and wants to support students in understanding why describe() matters.
• When I put the new start code in front of Amelie, she noticed describe() immediately, before reading the rest of the code. She saw the accessibility comment first and assumed describe() was responsible for what was drawn on the canvas. She tried changing colors inside describe() and expected it to change the canvas output.
• Most teachers were unfamiliar with describe() and screen readers and were unsure how to explain it. 12 of 17 teachers had never heard of the function before the survey and 11 said they'd "definitely" need to explicitly teach it. They recognized the importance but noted that it adds a layer of complexity for beginners who are still learning the basic structure of a p5.js sketch.
• There was broad support for accessibility, but mixed opinions about implementation. While most teachers rated the importance of including describe() as a 4 or 5 (on a 5-point scale), their final recommendations were split. Some wanted it in all sketches, other preferred it in an accessibility-focused lesson or for more advanced users. Many echoed concerns about "clutter" or overwhelming students too early.
• Most teachers (11/17) rated describe() as moderate to high source of distraction (3 or above), especially when students are first learning to interpret syntax, function structure, and logic.
• Amelie wanted help understanding code structure more generally. She said she appreciated the idea of describing what her code does, but what helped her most was when I mocked up plain-English comments like // this sets up the screen or // this draws shapes every frame. She said "This is what I would want. Otherwise I have no idea what setup and draw do, only what describe does."

This is clearly a feature worth keeping and discussing, but the way we introduce it matters. While I write this I am reminded that we are trying to change coder behavior (to think about accessibility throughout their project) and to promote empathy for screen reader users. I think we will likely need:

• stronger in-context guidance or comments that scaffold how/why to write describe()
• thoughtful onboarding or sequencing (e.g. prompting to add describe() once the user shares their project)
• Optional: more plain language supports for all users.

To read notes from my user test with Amelie, click here. Lmk if you have any other questions about the tests!